Due to the increasing popularity of internet-connected user devices, such as personal computers, mobile phones, and the like, it is becoming common for wagering game providers to offer users of these user devices the opportunity to play wagering games over the internet. Generally, these wagering games are operated using a client-server architecture in which the user device acts as the client and a server operated by the wagering game provider acts as the server. The server operates the wagering games and communicates information about the wagering games over a network, such as the internet, to the user device, which displays the wagering games.
One such type of wagering game is a spinning reel-type wagering game. There are two common types of spinning reel-type wagering games. A first spinning reel-type wagering game includes a base reel set used in each play of the first wagering game. A memory device accessible by the user device stores data representing the base reel set. For each play of the first wagering game, the server determines an outcome for that play of the first wagering game and sends data representing the determined outcome to the user device. The user device displays the reels of the base reel set spinning and stopping in accordance with the determined outcome. A second spinning reel-type wagering game includes a base reel set and one or more additional reel sets each having an average expected payout percentage greater than an average expected payout percentage of the base reel set. The server stores data representing the base reel set and the additional reel sets. For each play of the second wagering game, the server determines: (i) one of the reel sets for use in that play of the second wagering game, and (ii) an outcome for that play of the second wagering game. The server then sends data representing the determined reel set and the determined outcome to the user device. The user device displays the reels of the determined reel set spinning and stopping in accordance with the determined outcome.
Due to the nature of the client-server architecture and the internet, at certain times there is an appreciable delay (of two to three seconds, for example) between the time a user initiates a play of a wagering game and the time the user device receives data from the server. For example, after the user initiates a play of the first wagering game described above, at certain times there is an appreciable delay before the user device receives the data representing the determined outcome from the server. This delay is not a problem, however, because the user device displays the reels of the base reel set spinning during this time period, and stops the reels in accordance with the determined outcome after receiving the determined outcome from the server. Because the memory device accessible by the user device stores data representing the base reel set, the user device does not wait to receive a reel set from the server and the user does not, therefore, experience any appreciable delay in game play during play of the first wagering game. That is, from the player's perspective, after initiating a play of the first wagering game, the reels immediately being spinning and, thereafter, stop to display an outcome.
The delay is problematic during play of the second wagering game described above. For example, after the user initiates a play of the second wagering game, at certain times there is an appreciable delay before the user device receives the data representing the determined reel set for use in that play of the second wagering game and the data representing the determined outcome from the server. That is, the user device does not display any spinning reels until it receives the determined reel set from the server, which may take two to three seconds. The user thus experiences a delay of, for example, two to three seconds between the time the user initiates a play of the second wagering game and the time the user device displays spinning reels of the determined reel set.
More specifically, for a play of the second wagering game, after the user places a wager and initiates the play, the user device communicates to the server that the user has initiated a play of the second wagering game. The server determines: (i) a reel set for use in that play of the second wagering game, and (ii) an outcome for that play of the second wagering game. The server sends data representing the determined reel set and data representing the determined outcome to the user device. The user device displays the reels of the determined reel set spinning and stops the spinning reels of the determined reel set in accordance with the determined outcome. Thus, after the user initiates the play of the second wagering game, at certain times there is an appreciable delay before the user device displays the reels of the determined reel set spinning, which may frustrate users, especially those who desire to play the wagering game as quickly as possible, and discourage them from continued play of the wagering game.
One previously proposed way to attempt to solve this problem with the second wagering game involves displaying, on the user device, the reels of the base reel set spinning after the user initiates a play of the second wagering game rather than waiting to display spinning reels of the reel set determined by the server. After receiving data representing the determined reel set, the user device then either: (a) stops the spinning reels of the base reel set and displays the determined reel set in accordance with the determined outcome, or (b) replaces the spinning reels of the base reel set with spinning reels of the determined reel set and stops the spinning reels of the determined reel set in accordance with the determined outcome. This previously proposed solution is ineffective, however, because the reel set initially displayed to the user is not necessarily the same reel set determined by the server and displayed to the user at the end of the play of the second wagering game. Users may be confused when they view an outcome that does not correspond to the reel set (i.e., the base reel set in this example) that the user initially viewed, or when they see that the initially-spinning reel set has been replaced with another, different spinning reel set.
The ineffectiveness of this proposed solution is apparent with respect to a proposed spinning reel-type wagering game that includes: (a) a base reel set having an average expected payout percentage equal to an average expected payout percentage of the proposed wagering game, and (b) a stacked WILDs reel set having an average expected payout percentage substantially higher than the base reel set and including a reel that has plurality of WILD symbols positioned adjacent to one another on the reel (i.e., a stack of WILD symbols). Applying the previously proposed solution to this proposed wagering game could result in the following scenario when a user initiates a play of the proposed wagering game. When the user initiates the play, the user device displays the reels of the base reel set spinning. The server determines to use the stacked WILDs reel set in the play of the proposed wagering game, determines an outcome of the play, and sends data representing the stacked WILDs reel set and data representing the determined outcome to the user device. After receiving the data, the user device either: (i) stops the spinning reels of the base reel set and displays the stacked WILDs reel set in accordance with the determined outcome, or (ii) replaces the spinning reels of the base reel set with spinning reels of the stacked WILDs reel set and stops the spinning reels of the stacked WILDs reel set in accordance with the determined outcome.
In either case, the initially-spun base reel set is replaced mid-play with the stacked WILDs reel set. Thus, for a certain period of time, despite the utilization of the stacked WILDs reel set for that play of the proposed wagering game, the user views a spinning set of reels that does not include a reel having a plurality of stacked WILD symbols. This reduces the enjoyment and anticipation associated with a reel set having multiple stacked WILD symbols that a user would normally be able to view while the reels are spinning. The user may also be confused when the user recognizes that the base reel set initially displayed to the user and viewed by the user is not the same reel set displayed to the user at the end of the play of the proposed wagering game.
There is, therefore, a continuing need to decrease the amount of time it takes to complete a play of one of these wagering games over a network and to increase the potential rate of play of users playing these wagering games in a manner that does not confuse users, frustrate users, or reduce users' enjoyment of the wagering game.
Additionally, due to the nature of the client-server architecture and the internet, wagering games played over the internet are susceptible to being hacked and, therefore, data being transferred between the client and server may be intercepted and viewed by a hacker. More specifically, with respect to the second wagering game described above, a hacker may view reel set data and outcome data sent from the server to the user device and, therefore, know which reels are going to be used for a play of the second wagering game and the outcome for that play.
Another previously proposed solution that attempts to remedy the above-described delay problem for the second wagering game involves the server determining reel set and outcome data for each of a plurality of consecutive plays of the second wagering game and sending that data to the user device for use in those plays. In this previously proposed solution, for example, when a player initiates a play of the second wagering game, the server determines a reel set and a corresponding outcome for each of the next five plays of the second wagering game. The server sends data representing each reel set and outcome combination to the user device, which stores the data in a memory device. While the above-described delay will be present for the first play of the second wagering game (because the server determines and sends the data to the user device after initiation of the first play), the delay will, in some cases, be eliminated for the next four plays because the user device already stores the reel set and outcome data for use in those plays.
This previously proposed solution is ineffective, however, because it is susceptible to inbound snooping. For example, there are numerous network traffic capture tools that could allow a hacker to intercept the data representing the determined reel sets to be used in each of the next five plays of the proposed wagering game and the data representing the determined outcomes for those plays sent by the server to the user device. Even if the network traffic is encrypted, a hacker could reverse engineer the client code and/or trace its operation and view internal values of the decrypted data. Thus, the hacker could view the reel set and the outcome for each of the next five games prior to placing a wager on and initiating those games. The hacker could use this information to stop playing the game if the reel sets and/or outcomes are not favorable, or keep playing the game if the reel sets and/or outcomes are favorable. If certain of the outcomes are favorable and certain other outcomes are not favorable, the hacker could increase the hacker's wager on plays having favorable outcomes and decrease the hacker's wager on plays having unfavorable outcomes. It should thus be appreciated that this proposed solution, while at times eliminating the above-described delay for some plays of the wagering game, renders the wagering game susceptible to being hacked and exploited.
Another previously proposed solution that attempts to remedy the above-described delay problem involves the client itself randomly selecting the reel set upon initiation of a play of a game. This previously proposed solution would enable the user device to immediately display the correct reel set upon initiation of a play of the game. This previously proposed solution is ineffective, however, because it is susceptible to outbound hacking. Specifically, a hacker could modify the state of the code in the client and/or change the information sent to the server and, therefore, could consistently cause the most profitable reel sets (i.e., those having the highest average expected payout percentage) to be selected.
Another previously proposed solution that attempts to remedy the above-described hacking problems involves configuring the available reel sets such that each has the same long-term average expected payout percentage for the player. This previously proposed solution does not, however, allow for reel sets of varying value, which is a popular feature.
There is, therefore, a continuing need to provide multi-valued reel set switching functionality for a client/server slot game that avoids security risks and ensures fair game play for all users.